11-Nov-79 11:35:27-PST,000000559;000000000001
Date: 11 Nov 1979 1135-PST
From: CSD.GREINER
Subject: One minor, possible cause of some of the troubles
To: lenat at SUMEX-AIM
cc: csd.greiner, csd.smith

The ADVICE applied after EDITEing would (1) verify the various slots, updating
the overall Knowledge Base in the process, and (2) Set the modify flag on
that unit, (when that unit had been changed); in that order. Hence, every time
we ↑ed, or <CONTROL>D'ed out of some Add1Link, ... error condition, the modify
flag would sadly not be set. The order of 1 & 2 has been changed.
	Russ
-------
11-Nov-79 15:00:06-PST,0001170;000000000001
Date: 11 Nov 1979 1500-PST
From: CSD.GREINER
Subject: Ahaa!
To: lenat at SUMEX-AIM
cc: csd.smith, csd.greiner

Dave and I found another bug: NIL property lists were stored as NIL, not as (),
in the *.KB file. The reading mechanism would attempt to read in one
s-expression from some location, which would be, say NILas, or NIL78 in these
cases. Fix: Henceforth each unit will be followed by a <CRLF> in *.KB.
	Also: whilst reading in HOBBIT I found a variety of units non-existent.
These I merely created, (with no particular properties - which lead to above
discovery). They are Doors, Intelligence, HalfElf, Humanoid and Hobbit.
I also noted various units which had had NIL values earlier (as they had
defective property list structures.) These I updated by making their prop-list
a real list, only. They are: OpensInward, HingeFirst, and OnWall.
Finally, I deleted outright PerceivedIn - it caused too much trouble
(it had all sorts of circular links, and incorrect values.).
	These corrections have all been made, see most recent HOBBIT.KB.
Russ
	Dave: Reminder re: UF-WRITENETWORK - it breaks when the file to
be written is unopened.
-------
13-Nov-79 10:37:57-PST,0001380;000000000001
Date: 13 Nov 1979 1037-PST
From: CSD.LENAT
Subject: Once again...
To: CSD.SMITH, CSD.GREINER

If you look at <CSD>LENAT>RLL.DIRBBLE.1, you can see today's bug:
A unit seems to have been written (in its entirety) smack in the
middle of another unit!  This is not "written" in our LISPish sense
but rather in your (Dave) file sense (i.e., the first few characters
of an atom are present, then theencroaching unit, then he last few
characters of an atom; before and after these fragments are meaningful
beginning- and ending- entries for the "outer" unit).  It seems
as if the FreeblockIndex (or similar) has simply thought that a certain
region was free, and written a unit there, when in fact it was not free
(equivalently, the old, outer unit got moved to new quarters but
the freeblockindex didn't get the change of address).  The previous
HOBBIT.B didn't have this problem; both outer and inner units were
fine and (to my knowledge) either unmodified or simply had a few inverse
links added to theIr existing data.

The two .kbs ard copied as SAVEHOBBIT.KB-- and SAVERLL.KB-- where
I forget the numbers that -- represent (but there'll only be one such
file for each name).   Note that Russ changed UP-PUTUNIT; see 
<CSD.LENAT>FRED for the latest version.  It removes U from InCoreList
even if it appears that U isn't in core after all.

Doug
-------
14-Nov-79 00:35:48-PST,0000848;000000000001
Date: 14 Nov 1979 0035-PST
From: CSD.GREINER
Subject: Progress
To: csd.smith, lenat at SUMEX-AIM
cc: csd.greiner

Well, things seem to work fairly well tonight, with only a few problems.
Minor one: Cleanup is still not compiling my RLL file, even though RC is in
the CLEANUPOPTIONS variable. Any ideas why?
Major one: Some of my longer Units now have a property named "--"! Needless to
say, some bonafide properties are thereby lost. See RDG.DRIBBLE (scan for "--",
or for PRINLEVEL). Any theories? This shouldn't happen - see bottom of page 
14.19. Those "--"s are in the file itself, read it using some editor.
	Finally: my last sysout is on <CSD.SCRATCH>RSAV, for what it is worth.
Doug: I'm been working sans HOBBIT, figuring it was too clobbered to be 
worthwhile. True?   Hope your cold is better, by the way.
	Russ
-------
16-Nov-79 21:31:43-PST,0000000281;000000000001
Date: 16 Nov 1979 2131-PST
From: CSD.SMITH
Subject: Re: Misc
To: CSD.GREINER, lenat at SUMEX-AIM
In-Reply-To: Your message of 16-Nov-79 1951-PST

I have considered the multiple knowledge base theory but it doesn't suggest
anywhere specific to look.  Its possible.
-------
17-Nov-79 11:18:59-PST,0000801;000000000001
Date: 17 Nov 1979 1118-PST
From: CSD.SMITH
Subject: HOT DAMN!
To: CSD.LENAT, CSD.GREINER

I think I found the culprit thats been causing so much trouble.  An extra
EVALV inside the BOUNDP in UP-UNIT?  This explains why you've been having
the problem and not me.  UP-UNIT? is only referenced inside of UP-GETUNIT in
CORLL, and in such a way that the worst that could happen would be to get the
unit on the incorelist twice.  Some of your functions reference UP-UNIT? which
may have caused the loss of recent changes to the
units by overwriting the value cell for the unit (thinking it was not in
core, and not even bound).
The most recent CORLL.EXE has this fixed, as well as some extra checking in
the pageing functions which should make any further debugging easier.

Dave.
-------
16-Nov-79 13:46:04-PST,00000719;000000000001
Date: 16 Nov 1979 1345-PST
From: CSD.LENAT
Subject: Extraneous "InCore" units
To: CSD.SMITH
cc: CSD.GREINER

I noticed on my last run that HOBBIT.FREEBLOCKINDEX was one such unit.
Delving into the trace, I found that the very first time it was PUT,
it caused a release and then an assign of the same block (but with a
larger size), but it then did NOT print a "Bumping.." message.  so perhaps
there's some branch of all that code that does not terminate in bumping.
Later reading of  it back in must have caused a second copy to get stuck
on (CDR HOBBIT). Probably the value cell itself was OK, or we'd be in worse shape
now  (maybe this IS the source of some f our aggravation earlier).

Doug
-------
16-Nov-79 15:23:57-PST,000000957;000000000001
Date: 16 Nov 1979 1523-PST
From: CSD.SMITH
Subject: Re: Extraneous "InCore" units
To: CSD.LENAT
cc: CSD.GREINER
In-Reply-To: Your message of 16-Nov-79 1346-PST

This is entirely explainable.  HOBBIT.FREEBLOCKINDEX could have its block
released, reassign a bigger block in the same place (the block after must have
been free also and the two free blocks were collapsed),  and then not bump
the unit because it had been changed in the process of trying to write it out.
When it starts the procedure for writing out units it resets the modifyflg to
NIL, then after assigning blocks etc, it rechecks the unit to see if modifyflg
is T.  If it is it doesn't bother to actually write or bump.  Your observation
that this unit ended up on incorelist twice may be usefull.  Have you noticed 
this correlation for any other units?  Do you have a dribble of that run?  Will
check into this one and see if the cause-effect is obvious.

Dave
-------
 8-Dec-79 23:27:21-PST,00000000740;000000000001
Date:  8 Dec 1979 2327-PST
From: CSD.GREINER
Subject: ouch, another one.
To: csd.smith
cc: lenat at SUMEX-AIM, csd.greiner

	Dave - when you have a minute, (and if you think it will help) could 
you help me compress a copy of RLL.KB. Its
unit index is clobbered (edit RLL.KB, and search for %., to see an impact of
this trouble - by the location of LivesInLocation.) As best I can tell, nothing
else has yet been affected. Note this 
bug was present in the Dec 3rd version of RLL.KB, and so is (probably) not due
to my monkeying around with CORLL.
	Doug - when can we store a copy of RLL & HOBBIT on <HPP.MOLGEN>? It 
shouldn't take terribly long to clear away the debris still cluttering that 
directory...
	Russ
-------
10-Dec-79 18:01:22-PST,0001876;000000000001
Date: 10 Dec 1979 1801-PST
From: CSD.GREINER
Subject: [CSD.GREINER: I think I know the problem:]
To: csd.smith
cc: csd.greiner, lenat at SUMEX-AIM


	First, before I forget, <CSD.LENAT>FIX holds the functions Diagnose and
(still to be written) ReportAll, which you may want to incorporate,
mutatis mutantis, into CORLL. (eg a name change, or whatever.) Also, perhaps
you could give me a hand tomorrow, when I massage RLL.KB, based on the diag-
nosis stored in DIAGNOSE.DEC10. I/We'll have to delete a few units, and ...
	Onto what-I-suspect-to-be-the-problem: Consider what might happen when
RLL.UNITINDEX is being bumped. If it has not grown, it will be stored at the
same location whence it emerged; all well and good. But, let us suppose it now
longer fits into that location.  In some order, the following things occur:
a new location is found for RLL.UNITINDEX, RLL.UNITINDEX is written there, and
the value is placed for (ASSOC 'RLL.UNITINDEX (UA-GETVALUE RLL.UNITINDEX
UnitList)). The problem lies with the precise order of these operations...
Imagine a location is secured for RLL.UNITINDEX, and RLL.UNITINDEX is
written there. Now comes to time to update RLL's unit index, and so 
RLL.UNITINDEX is read back. 
RLL.UNITINDEX is then updated, and its modify flag is set true. Now that this
unit has been written out, the system proceeds with its fix up, and SETQ's
RLL.UNITINDEX to it's "I'm been written out" form, and its (correct) incore
value is ignored! Next time RLL.UNITINDEX is requested, the old, (incorrect)
value will be read in.
(Note: This above is just a conjecture which I have not further pursued. It
is so consistent with the current state of RLL that I thought I would propose
it. Realize also this same problem might effect RLL.FREEBLOCKINDEX as well,
with equally devistating (sp) ramifactions (sp).)

Russ
-------
25-Dec-79 12:56:52-PST,622;000000000001
Date: 25 Dec 1979 1256-PST
From: Lenat
Subject: Serious Mis-writing of UTIL
To:   GREINER

On UTIL.COM (latest version, i.e., on <MOLGEN>) I got the following
error while trying to read it in: bad compiled function BUMPING.  This
occurs just after the USERFN called SameKB gets read in.  What must have
happened is that, during file-writing, a GC occurred, and a Bumping...
messsage was printed, but alas got printed on the output file rather than
the terminal!!  I will look for an older version of UTIL.COM somewhere,
and barring that will try to TCOMPL UTIL, and barring that will give up.

Doug
-------
25-Dec-79 13:17:38-PST,710;000000000001
Date: 25 Dec 1979 1317-PST
From: Lenat
Subject: Bugs fixed
To:   GREINER

Russ,

The bug was ue to the fact that (at least on the various SUMEX-dwelling
WORK and WORK.COM files, the function WRITE calls PRIN1, wheras to be
safe it should really call PRIN1 with a second arg of TTY.  What I'm
doing is simply redefining WRITE to be WRITELNTTY.  This will exist on
MY WORK and WORK.COM files, and (if I can anage it) on MOLGEN's as well;
but note that <USESYS>CORLL.COM won't have it, so redefine WRITE.

Small bug:  Movd1 has an extraneous RETURN in it (i.e., no PROG exists),
and should get removed.

UTIL itself had no garbage, so I just recompiled it and my version is OK.

Doug
-------
25-Dec-79 16:38:19-PST,1457;000000000001
Date: 25 Dec 1979 1638-PST
From: Lenat
Subject: bugs bugs bugs
To:   GREINER

Grumble..  bah humbug...  etc.

I started upon my journey to fill in heuristics, and got about 2 feet.

I tried to use NU to create a new slot called BroaderRules (ie., heuristics
whose left hand sides apply whenever the current rule's LHS applies; ie,
in a superset of the situations in which the curr rule applies).  Some
difficulties:  Defns (and several other slots) were not recognized as such
by Slotp, because (even tho their Isa was proper) their AllIsas was NoEntries.
This took some fixing, and ultimately I gave up.  I think the PVE.. option
doesn't work properly, incidentally (it may still assume that Isa is an
atom). 

Also, the following are on Examples of PrimSlot, but aren't even units:
CoRefs ToXeqMe  FixListFn

Also,  I think that AllExamples is getting filled with a list of one element
all he time, namely only the last (most recent) entry on Examples!!!

Please do the following for me, before we get together if possible:
Fix up the world so that the (already existing, on my area) HEURS.KB
file will contain a unit called BroaderRules, NarrowerRules, StrongerRules,
and WeakerRules (the latter two refer to the Right Hand Side containing
a more /less  specialized version of this rule's RHS).  The0datatype should be
Rule (or heuristic, or similar; a new unit may be necessary for RuleType).

Thanks.


Doug
-------
 3-Jan-80 00:00:54-PST,386;000000000001
Date:  3 Jan 1980 0000-PST
From: Lenat
Subject: trouble in VerifySlots
To:   GREINER

No huge bug, just a gripe:  When I do NU(X Y), and Y had an
Inverse z   slot, then I change or delete that (during my editu of X),
z's Inverse slot goes away!  In fact, there may be a flaw in the logic
that says you should do ANYTHING to any of the OLD values of the slots.

Doug
-------
 3-Jan-80 00:52:14-PST,754;000000000001
Date:  3 Jan 1980 0052-PST
From: Lenat
Subject: more small bugs
To:   GREINER

There is a var. being bound called ThePlist, which I suspect is
a misspelling SOMEWHERE of ThePList (being bound at the top level,
i.e., you probably used it INSIDE a (LAMBDA (ThePList)..), and it's
worked so far because no one called that fn recursively.

The Jan02 trace shows an error in which I changed a unit (using PUTPROP,
then EDITU, I think), and in which the changes never got recorded.
Scan for the word Diagnose, and note the particular Diagnose of HEURS
that reported the error (unit on Incorelist is not in core, or similar).
This is not supercritical, as I may have munged it myself somehow using
non-EDITU prop list commands.

Doug
-------
25-Jan-80 22:52:52-PST,0004666;000000000001
Date: 25 Jan 1980 2252-PST
From: CSD.LENAT
Subject: ATTEMPT TO USE RLL TONIGHT
To: CSD.GREINER

I tried.  It is in so fragile and incomplete a state that every time
I tried to do ANYTHING, there were some bugs in my path.  This is not
tolerable; I am somewhat at a loss to correct the situation.  It's mostly
my fault, since I have not stayed on top of the code, but a large measure
of it comes from your willingness to make a dozen changes simultaneously
and implement each of them 90% of the way (e.g., your cavalier attitude
about not checking for every possible occurrence of S when you rename S
to S').  In a system as big as ours, we just can't do that kind of thing.
If anyone is going to use the system, it must work cleanly.  Get and Put
should work (yes, I got an error from PutValue tonight, when the system
tried to APPLY (ToPutValue x), and x was not a unit -- this was a call
left in, not one I typed in tonight.  SpecsTyp and GenlTyp and their *'s
were no longer units, but were mentioned all over the place; I (re?-)added
them.  
They were, in paricular, mentioned in the HighLevelDefn of AllGenls.
Also, uTrusting got to be NIL and funny things began to occur (I think
because only a fraction of slots have Datatypes of any kind).
PossibleSlots(x) fails almost always.
The concept behind the slots of a task is quite obscure, and not
explained by that most elusive of entities, the good example.  If only
there were one (1) clear task in the system, all the slots would
probably be obvious.  

I am tired of stalling our research, forever waiting for trivial bugs in
the RLL code to be fixed.  We wouldn't put up with this from CORLL, and
shouldn't from RLL either.  We must get one clean running version,
and encase it in lucite.  Then, let Dave and other hackers at it to
improve it in various ways (the macros you wer playing with is a 99% waste
of time; our time is spent 99% in debugging and talking, 1% in running,
and of the time spent running, the place for maximal improvement is
probably in the superfluous copying of list structure, not in cpu time
itself). You and I are doing research on the discovery of heuristics,
and to do that we need a vehicle (RLL); it is time to stop working on
RLL for its own sake (though we can let others do that).  The whole
point of RLL was to make it easier to input knowledge, not harder; yet
I find hours passing while I sweat to enter even a few trivial morsels
of knowledge, and then I give up, beaten.  Ican't even add new
properties, because THAT mechanism is screwed up (the one which lets
you dynamically tell the system that YES, you really did want S to be
a slot name; perhaps the bug there is that no Datatype is initializeda
for the neonatal S unit).

The names for slots are obscure at best, and there is no easy way for
the poor user to find his way around (your document does help, though).
Let others cause the slots to proliferate, we should concentrate on
cleaning up the system (that means taking things OUT, not adding
new mechanisms), getting all the bugs out, getting all he names
changed over to the current ones, getting a good document produced,
etc.  We should get a few agendas (NumberTheory, GameInventing, 
GraphTheory,...) set up, each with at least a few tasks, and work toward
making them run.  Let THAT drive us, not some abstract sense of
purity, generality, etherealness, completeness, etc.

Forgive this somewhat long and acerbic note, but I feel us sinking
in some sort of trap, and we must extricate ourselves before it's too
late.  Try to do some of the cleaning up this weekend and next
Monday and Tuesday (e.g., if every slot is supposed to have a Datatype
slot, then see hat each one really has one, an OK one, and that
any new slot will automatically get an OK one.  The philosophy should
be much less of the initialize-at-creation-time (which you probably
inherited from he horrible practices of UNITS) but rather the
infer-whenever-needed, which lets you decide at any point that X is a
slot).   I will be in at 8am Wednesday morning, and want you to be,
too (yes I know that's early for both of us), so we can work together
on an acceptable schema for agendae, tasks, rules, etc.  This means
we will try to enter (or replace) a body of units, and get the whole
system turning over.  I really would like to be in knowledge-entry mode
by the end of the week; you will find it infinitely more exciting than
the drudgery we're now enmeshed in.

Doug

PS: your talk today went much better than I expected; with a little
work next week, we can probably improve it even more.
-------
22-Apr-80 02:22:07-PST,0000372;000000000001
Date: 22 Apr 1980 0222-PST
From: CSD.LENAT
Subject: STATUS
To: CSD.GREINER

KBs are up to date; no .exe files thoguh (you can make them of course).

Defn(HowToProcess) got wiped away, since it had a HLDefn (though a bogus
one).  The correct Defn is on file HDEFN; I may have forced it successfully
to be kept around on RLL.

Things worked OK.

Doug
-------
28-Apr-80 23:36:29-PDT,00000000264;000000000001
Date: 28 Apr 1980 2336-PDT
From: CSD.LENAT
Subject: RLL
To: CSD.GREINER

Specializations.Defn got into trouble (due to strange attempted
recursion by functinal OneOf); Specializations.HLDefn is fine.
Did not fix it, as it was not essential.
Doug
-------
 3-May-80 04:17:10-PDT,0001336;000000000001
Date:  3 May 1980 0417-PDT
From: CSD.LENAT
Subject: STATUS
To: CSD.GREINER

Alls well.  USEME is current and fresh (kBs just loaded in).
*.EPAGES done, though superfluous.

Many minor bugs (which weren't there a while ago; you should test
out your changes on a batch of examples whenever possible); e.g.,
EmptyValue is sometimes given (unt slot) as arg, when it expects
just a single argument (slot); hence, I check to see if it IS
given a 2nd arg, in whcih case it ignores the 1st!  Also, several
units had their MyOrderedSlots there when Prototypes was NOT ordered!
Had to remove those by hand.  Also, some of the slot combiners are not
working right.  Also, HLTypeParser is doing funny things; it produced
an expressions of he form (APPLY* xxx (FUNCTION (APPLY* ...))) where
that last (FUNCTION (APPLY*...)) was not appreciated by lisp.  I got
this to work right by the following hack:  if argname is provided
(NonNULL) then we let your version go thru, else we put an extra
(LAMBDA (zz) ... zz); this is to deal with FnForVerifyingElement.

Wild fluctuations in list cell space; from 25k to 0 in a minute or
so; what does such things?  We are going to get killed soon if we
don't track this down.  

The SOS file worked; I don't recall whether it was "to the bitter end".

See you soon.
Doug
-------
 3-May-80 19:15:28-PDT,00000001008;000000000001
Date:  3 May 1980 1915-PDT
From: CSD.GREINER
Subject: All set
To: csd.lenat
cc: csd.greiner

I didn't get a chance to Put the KBs, but they're safe in USEME
and *.EPAGE, as per request. Everything seems to be in working order.
I wont swear that Charisma now works totally, but it did on one example...

Also, if you get a chance, look thru WORRIES once in a while, to see
if any of these messages really are significant. (There were about 100
earlier today, most of which corresponded to things I've fixed. I left
those which seemed HOBBIT related.)

When EmptyValue asks you a question, the usual answer will be Yes --
for a while I erroneously had TypicalPrimSlot.Defn as EmptySlot, not
DefaultSlotDefn (which gave rise to those erroneous arguments.)

At times FormatIsList? may ask questions -- it currently has no way of knowing
the format of, say, MapUnion's results. Tell it.

I've a performance tomorrow, so probably won't be in... Will be in Monday for
sure.

Russ
-------
12-May-80 13:06:24-PDT,00000000226;000000000001
Date: 12 May 1980 1306-PDT
From: CSD.LENAT
Subject: BUG
To: CSD.GREINER

When Datatype is changed, it deletes Rangetpye, which when changed
deletes Datatype;  this infinite loop works both ways, I think.
Doug
-------
 2-Jul-80 15:36:22-PDT,00000818;000000000001
Date:  2 Jul 1980 1536-PDT
From: CSD.GREINER
Subject: Trouble
To: csd.lenat
cc: csd.greiner, csd.smith, csd.hines

Doug,
	I closed the KBs yesterday, and opened them today, sans complications.
When I tried doing a DI(Anything S), I got into trouble. (Some problem with
the Defn of OneOf.) At any event, I left it (temporarily) in this limbo, by
doing a SYSOUT onto <CSD.GREINER>RLL. There was no more space on your directory.

Question: Where are the *.PAGE files? Or are *.KB files used? I couldn't find
them.  Perhaps CORLL now uses *.KB files -- but those files haven't been used
since yesterday!!  Feel free to delete the RLL.EXE file on my directory,
and the corresponding (virtual)*.PAGE files.... <CSD.RLL>RLL.EXE is RLL in
its initial state.

Hope you enjoyed your vacation.
	Russ
-------
 3-Jul-80 16:50:52-PDT,00000843;000000000001
Date:  3 Jul 1980 1650-PDT
From: CSD.GREINER
Subject: Solved.
To: csd.lenat, CSD.HINES
cc: csd.greiner, csd.smith

Turns out OPENFILE does the right thing; those *.PAGE files did exist.
However, DIR doesn't know about them until those files are closed.
(Due to the errors which happened when I tried to SYSOUT, that closing
never took place.) Exhale.  According to DEA, LOGOUT is smart enough to close
the file automatically.

Larry: I thought your difficulties were due to this problem. Checking your
TRACE file, I now have another theory.  You need to have CSD.LENAT on your
path.  This is best done by redefining DISK, during LOGIN. Feel free to
copy my LOGIN.CMD file.  Mutatis mutandis, it should do the job.
(Be sure to leave CSD.RLL there, as that will soon be where the misc
*.KB files will reside.)

Russ
-------
 6-Aug-80 14:21:06-PDT,0000000722;000000000001
Date:  6 Aug 1980 1421-PDT
From: CSD.FREEMAN
Subject: Rll
To: csd.greiner

I did the following today.

@corll-db
(LOAD 'UTIL.COM)
(START)

Then it started printing out all the things that it read in, snore.
It asked me if I wanted to be in readonly mode, i said yes,
then asked me if I wanted to read in any knowledge bases, yes,
then it told me that it didn't know me, which seems reasonable,
asked me what I wanted to be called, I responded with AndyFreeman
and then it broke in PartsParser, I logged out and tried again
after saying no to readonly mode, same error.

I did all this in <3scratch> but unfortunately deleted the files
before I thought about telling you of the error.

andy
-------
17-Sep-80 16:07:56-PDT,0000364;000000000001
Date: 17 Sep 1980 1607-PDT
From: CSD.FREEMAN
Subject: RLL bomb
To: csd.greiner

In other words, it blew up.  It complains that ToGetValue and ActualGetValue
are bad slots.  I couldn't find the unit for ActualGetValue, but ToGetValue
was there.  I was using <csd.rll>rll.kb.6 (and 5) and the most recent versions
of util and corll from <csd.rll>.
-------